前言
昨天我們針對測試中發現的問題做了修正。但這裡有個容易被忽略的問題:改完之後,你有留下任何紀錄,說明「這次改了什麼、為什麼改」嗎? 如果沒有,你的範本正在悄悄累積一個風險——沒有人(包括未來的你自己)知道它是怎麼演變成現在這個樣子的。
今天要談的,是把「版本控制」這個軟體工程裡的基本習慣,帶進 Prompt 範本的維護工作裡。

一、為什麼 Prompt 範本值得被當成「資產」認真管理
回顧 Day 2,我們談過自動化的核心價值在於:把「每次重新溝通」變成「一次投資、長期套用」。既然這份範本會被長期、重複使用,它的角色其實跟一段會被長期維運的程式碼很接近——而任何長期維運的程式碼,沒有版本紀錄,遲早會變成一團誰都不敢動的黑盒子。
Prompt 範本容易陷入這種狀況的原因,是它終究是一段「自然語言」,看起來隨時都能「順手改一下」,不像程式碼那樣有明確的語法規則會逼你謹慎。但正因為它改起來門檻低,沒有紀錄的風險反而更高——你今天順手調整了一句話,三個月後範本突然某個地方輸出跑掉,你完全想不起來是哪次修改造成的。
二、一份「修改日誌」該記錄什麼
不需要複雜的工具,一份簡單的修改日誌,通常只需要記錄四件事:
欄位 內容
日期 這次修改的時間
修改內容 具體改了哪一條規則、改成什麼樣子(建議直接貼修改前後的文字對照)
修改原因 為什麼要改?是哪次測試發現了什麼問題?(對應 Day 21 除錯時的具體案例)
驗證結果 改完之後,有沒有重新測試?結果是否符合預期?
例如一筆紀錄可能長這樣:

日期:2026/08/28
修改內容:在禁用清單新增「經過詳盡的分析與評估」,原句改為要求直接陳述結論
修改原因:Day 20 測試時,發現事件摘要章節出現冗贅修飾語,不符合 Day 9 的精簡風格要求
驗證結果:重新測試同批資料,該用語未再出現,其餘章節未受影響
這樣的紀錄,讓你在未來遇到類似問題時,可以直接查閱「這個問題我是不是已經處理過」,而不是每次都從頭摸索。
三、版本控制帶來的三個實際好處

1. 可以回溯,不怕改壞
   如果某次修改後,發現範本反而變得更不穩定,你可以清楚知道「回到上一版」該回到哪裡,而不是憑印象試圖「改回原本的樣子」——這種靠印象的復原,往往改不回真正原本的狀態。
2. 累積屬於你自己的「除錯經驗庫」
   隨著時間累積,你的修改日誌會變成一份珍貴的參考資料——很多問題其實會重複出現(例如換了新同事負責填寫備註欄位,又出現類似的格式不一致問題),有紀錄在手,你能立刻找到過去怎麼解決類似狀況,不用重新診斷一次。
3. 方便交接與團隊協作
   如果未來這份範本需要交接給其他同事,或多人共同維護,修改日誌能讓接手的人快速理解「這份範本為什麼長成現在這個樣子」,而不是拿到一份規則堆疊、卻不知道每條規則背後脈絡的文件。
   四、實務上該怎麼記錄,才不會變成額外負擔
   版本控制聽起來像是額外的工作,但其實不需要複雜的工具——一份簡單的文字檔或試算表,依照上面的四欄格式,每次修改後花一分鐘記錄,就足夠。真正重要的不是工具多先進,而是**「有沒有養成習慣」**。建議把它跟 Day 21 的除錯流程綁在一起:每次除錯完成、確認修正有效之後,順手記一筆,而不是拖到之後才想起來要補記錄。
   五、今天的行動練習
   把昨天 Day 21 做的修正,依照今天的四欄格式,補寫成第一筆修改日誌紀錄。如果之前累積過幾次調整卻沒記錄,可以趁現在回想並補上大致的紀錄,作為這份日誌的起點。

小結
今天談的觀念很單純:把 Prompt 範本當成一份會長期演化的資產來對待,而不是一份「想到就順手改」的文字檔。 一份簡單的修改日誌,能讓你在未來回溯問題、累積經驗、甚至交接工作時,省下大量重新摸索的時間——這正是 Day 2 談的「可重複性」,在長期維護層面上的具體展現。
下一篇,我們要往下追問一個更進階的問題:當你改出了新版本的 Prompt,怎麼客觀證明「新版真的比舊版好」,而不是憑主觀感覺說「這版好像比較順」?